After completing this lesson, you’ll be able to:
As a resident FME expert, you are often asked to translate data (particularly the community map) between formats. You realize it would be much simpler if you created a workspace to do this, regardless of format, and let the end-users carry out the translation themselves. You've started building a workspace, but now you need to add fanouts to ensure the users receive data in the form they expect.
This would make an excellent use for an FME Flow Data Download service in the future, but for now, we'll let the users run the workspace in FME Workbench. See the FME Flow Authoring learning path to learn more about creating self-serve data download workflows.
Open the starting workspace (C:\FMEData\Workspaces\AdvancedDataTransformation\exercise-use-fanouts.fmw) in FME Workbench (2025.1 or later).
You can see from the Navigator that this workspace reads in a community map file, Geodatabase, and writes out to the Generic format:
The workspace provides four format choices to the user, controlled by User Parameters > OutputFormat.
The Generic format lets the user choose which format to write. You can learn more in the documentation.
The reader feature type is merged, meaning it will read all features into one stream rather than individual feature types per feature class. You can tell the feature type is configured that way because it is named <All>. The writer feature type is set to write to a single feature type named NewFeatureType.
Examining the User Parameters shows that the workspace lets users choose which feature types to read. The user configured it this way by linking the FEATURE_TYPES parameter to the Reader Parameters > Features To Read > Feature Types to Read parameter.
If the workspace is run now, the user can choose the feature types and format, but FME will return the results in a single layer/file. This result could be more optimal. Let's change the workspace so the user receives separate layers/files for each feature type. We'll also zip the output for convenience.
We want to output features to their original table. To do this, we need to know where they came from, which is obtained from a format attribute called fme_feature_type.
Inspect the properties for the writer feature type. Set a fanout by choosing fme_feature_type as the attribute setting the Feature Type Name.
Your dialog should look like this:
Click OK. The name of the feature type on the canvas will change to <@Value(fme_feature_type)>
to reflect the use of a fanout.
In the Navigator, find the Destination Generic (Any Format) Folder writer parameter:
We will create a zipped folder to contain all of our files. Double-click the parameter and set the location of an output folder (such as C:\FMEData\Output\Training
), then at the end, type \CommunityMapping.zip
.
Your full parameter value will look something like this:
C:\FMEData\Output\Training\CommunityMapping.zip
This will create a zipped file called CommunityMapping.
Save the workspace and run it with Run > Prompt for Parameters enabled. When prompted, select some source tables to read (include at least the GarbageSchedule plus one other). Set Esri Shapefile as the format to write. Ensure your path reflects that you will be writing a zipped file:
Click the Run button to run the translation. Examine the output folder. A zipped folder has been created, which contains all the selected tables that have been written back to Shapefile format:
Now, you have a solution that almost anyone can open and run. If you publish the workspace to FME Flow, the same user parameters will be available.
Did you notice that FME handled the different geometry types and output the files with the geometry as part of the name? It’s a Shapefile format thing. FME can never – and will never – write more than one geometry type to the same Shapefile .shp file.
The one drawback with the output is that each Shapefile has attributes for all source tables. To avoid that outcome, you would need to use a dynamic translation. We cover those later in this learning path.\
The city plans to greatly expand the size of these layers soon. Therefore, they'd like the output of the workspace to be tiled into four spatial quadrants, writing out each layer in four separate files.
This is easy to accomplish with the Tiler transformer and a dataset fanout.
Add a Tiler between the two feature types:
Configure it like this:
Define Tiles By | Number of Tiles |
Columns | 2 |
Rows | 2 |
Click OK.
These settings will add grouping attributes to each feature, _column and _row, which represent which column and row they fall into spatially.
Now that we have attributes we can use to group the output, we can use them in a dataset fanout expression to construct a custom path.
Expand the CommunityMapping [GENERIC] writer in the Navigator and double-click Fanout Expression:
Notice that opening the parameter this way automatically enables Fanout Expression and moves the ZIP part of the path into the Fanout Expression.
But we want to add the _column and _row attributes to the expression as well, so click the drop-down arrow and choose Open Text Editor:
Construct or paste in the following:
CommunityMapping.zip\@Value(_column)x@Value(_row)\
This will create folders within CommunityMapping.zip that reference the tile like this:
The output of the writer feature types will then be spatially split between these folders, so each will contain shapefiles named for their original layer.
Click OK twice to close the dialogs.
Before we run the workspace, we should delete the ZIP file we just wrote. Otherwise, we'll just add data to it. Find the ZIP file at C:\FMEData\Output\Training\CommunityMapping.zip and delete it.
Then, save and run your workspace.
Go back to C:\FMEData\Output\Training\ and look at the contents of the ZIP file by double-clicking it. You should now see the tile folder structure, with each folder containing its own shapefiles:
If your output doesn't match the above, ensure you have configured your Fanout Expression properly.
Now the workspace uses both feature type and dataset fanouts for ultimate control over the output!